它為了解決什麼問題而生？

Javascript 的弱型別特性賦予了開發者相當大的彈性，但也造成了一些語法錯誤無法被直接發現，往往要等到出現 runtime error 才會被察覺。這一特性使得當專案不斷成長時會觸及瓶頸，讓它不適合用於大型專案。

於是微軟開發出了 TypeScript，並在加入了包含型別判定在內的許多特性，有些人會如此介紹 TypeScript:

TypeScript 是 Javascript 的超集(Superset)。

白話文就是 Javascript 能做到的，TypeScript 也能做到，而且還有更多東西可用。

約束的哲學

本人剛開始接觸程式語言的學習歷程是這樣的：
VB.NET → C++ → PHP → Javascript

因此我而言，強型別反而更讓我自在，但是對於習慣 Javascript 弱型別的開發者而言，TypeScript 的特性反而會讓他們感到綁手綁腳的，而且單從 IDE 輔助的角度來看的話，Jsdoc 依然可以讓開發者定義型別使 IDE 顯示變數的型別，也可以讓 bundler 透過 jsdoc 的 typedef 生成 .d.ts 檔案，因此我並沒有「TypeScript 比 Javascript 好」的意思，畢竟 TypeScript 提供的一些特性，諸如：Interface, Generic, Inheritance...我其實很少使用，更多時候我單純是在使用 TypeScript 的強型別特性帶來的約束效果。

有人說 Design Patterns 是因為程式語言的缺陷而產生的東西，但是在我看來它是一種約束；包含 SOLID原則在內的各種原則在我看來也是一種約束；PSR (PHP Standards Recommendations) 在我看來也是一種約束；命名規則在我看來也是一種約束；Pure function 在我看來也是一種約束，缺乏約束的開發過程會讓開發者淹沒在「可能性之海中」。

可能性之海

如果一個程式所仰賴的所有變數和外部資源，都視作一個狀態機的一部分，我們可以把程式的運作想像成這樣的一張圖：

通常開發者對於自己程式的初始狀態會非常熟悉，因此距離初始狀態越近變化，開發者通常能夠控制它們的運作在預期內，但是隨著使用者累積的操作越來越多，程式狀態距離初始狀態越遠，開發者對於這些狀態的了解就越來越薄弱，最終程式有可能進入了「預期之外的狀態」，也就是發生了 BUG 。

這就是為什麼重新啟動、清除快取等等操作可以修復部份的程式錯誤，就是為了把整個狀態機復歸回最穩定的初始狀態。

上述是程式運作時的可能性之海，開發過程亦是如此，Javascript 允許一個變數是各種型別；允許一個方法/屬性是各種型別，當允許的狀態越多，開發者要顧慮的情況就越多，疏忽掉的可能性也就越高，透過 TypeScript 的強型別來約束母體空間的大小藉此降低錯誤發生的機率。

波茲曼熵

波茲曼熵可以寫作：

S = k ln W

其中 W 是系統的狀態數，由此可知當系統可能的狀態越少，熵就越小。

其實不難發現，Dokcer 是在降低環境的可能性；NPM 是在降低套件仰賴的可能性；TypeScript 是在降低型別的可能性；單一職責原則是在降低組件的可能性...。

宇宙的熵在升高，有序度在降低，像平衡鵬那無邊無際的黑翅膀，向存在的一切壓下來，壓下來。可是低熵體不一樣，低熵體的熵還在降低，有序度還在上升，像漆黑海面上升起的磷火，這就是意義，最高層的意義，比樂趣的意義層次要高。
--三體